fix(runtime): give debug HTTP module fetches a 30s request budget - #552

Summary

Every HTTP module request carried a flat 5-second NSURLRequest timeout. Dev servers transform cold modules on demand, and real toolchain responses have been measured at 5–9s — so valid fetches expired mid-transform. A timed-out dependency fetch left the module unregistered, its subtree stayed undiscovered by the graph walk, and instantiation fell back to the blocking synchronous loader (the module graph walk missed warnings), in the worst cases stalling the JS thread for minutes.

• One timeout policy, one place. ModuleFetchTimeoutInterval() reads RuntimeConfig.IsDebug: 30s in debug runtimes, the original 5s in release. It now backs the synchronous NSURLConnection fetch, every async NSURLSession request, and the async session's own default — whose stale 10s never actually applied, since each request overrode it to 5s.
• Retries bounded by the graph budget. Two 30s attempts plus the retry delay can outlast the 60s pumped graph wait, so the enclosing load's deadline (AsyncGraphLoad.fetchDeadline) is plumbed into each async attempt: requests clamp timeoutInterval to the time remaining, the 120ms transport retry fires only while budget is left, and no request is issued that could only complete past the deadline. The sync-fallback path — the post-deadline recovery mechanism — keeps its existing single retry.
• Unpumped loads (dynamic import() of an HTTP root) pass a zero deadline and keep unbounded fetches; nothing there waits on the 60s budget.

Diagnostics are unchanged: the graph-miss warning still fires, and 404 / MIME / syntax / transport failures keep their existing messages.

Test plan

• New ModuleTestServer routes: delayed /esm/slow/* transform routes and a /esm/request-stats.json introspection route so specs can prove a module was fetched exactly once (no retry, no sync-fallback round trip).
• New specs in HttpEsmLoaderTests (build-aware via the debug-only canonicalizeHttpUrlKey export):
  • a 7s-delayed module resolves inside the debug budget on its first request (rejects in release);
  • a slow HTTP parent re-exporting a child resolves with one request per module;
  • a pumped require() through a local→HTTP re-export boundary waits for a 7s leaf.
• Existing network timeouts spec updated to wait out the debug budget (delayMs 32000 vs the former 12000).
• Full TestRunner suite on CI.

Local validation status: both modified translation units pass clang -fsyntax-only; build-for-testing of the TestRunner scheme succeeds. A local on-device run could not validate further in this environment: the local Xcode is newer than CI's pinned toolchain, so the app needed local-only build overrides, and the resulting TestRunner app crashes at startup identically on pristine main (uncaught exception in RunMainScript) — a host-environment issue that predates this change. The timeout policy itself was additionally verified earlier against the published runtime via an effective-request-override experiment on a real dev session (delayed 5–9s responses stopped timing out; graph misses disappeared).

Summary by CodeRabbit

• Bug Fixes
  • HTTP module graph loads now share a time budget, preventing individual requests from exceeding the remaining time and skipping transport retries when there isn’t enough time left.
  • Request timeouts are 5 seconds in release builds and 30 seconds in debug builds, with the same timeout policy applied to synchronous and asynchronous requests.
  • Pumped require() calls use the same time budget for waiting, fetching modules, and retries.